perm filename CBUGS[CMP,LSP] blob sn#211948 filedate 1976-04-22 generic text, type C, neo UTF8
COMMENT āŠ—   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	(COMMENT THIS FUNCTION GETS LOSTVAR-ILOC1)
C00008 ENDMK
CāŠ—;
(COMMENT THIS FUNCTION GETS LOSTVAR-ILOC1)

(CMP (LOSEVAR) (LAMBDA NIL ((LAMBDA (A B C D E) D) 1 2 3 4 5)))

(COMMENT THIS BUG WAS SUBMITTED BY BEATRICE FROCK OF THE ROYAL
	 INSTITUTE OF TECHNOLOGY DEPARTMENT FOR COMPUTER SCIENCES
	 NUMERICAL ANALYSIS S-10044 STOCKHOLM 70 SWEDEN STOP HER
	 FUNCTION FOR PRODUCES A LOSTVAR-ILOC1 WHICH APPEARS TO BE
	 THE VALUE OF THE (EVAL U2) STOP THE BUG SEEMS TO BE DUE TO
	 THE EVAL IN PREDICATE CONTEXT IN THE COND IN SIDEEFFECT
	 CONTEXT STOP FORSHORT PRESERVES THE BUG WHILE FORFIX CURES
	 IT)

(DEFPROP FOR
	 (LAMBDA (A U1 U2 U3)
		 (PROG NIL
		       (SETQ A 0)
		  NEXT (EVAL U3)
		       (SET A (EVAL U1))
		       (COND ((EVAL U2) (RETURN)) (T (GO NEXT)))))
	 EXPR)

(DEFPROP FORSHORT
	 (LAMBDA (U2) (PROG NIL (COND ((EVAL U2) (RETURN)))))
	 EXPR)

(DEFPROP FORFIX
	 (LAMBDA (U2) (PROG NIL (COND ((WASEVAL U2) (RETURN)))))
	 EXPR)

āˆ‚11-OCT-75  1400	L,HJS @ NBST   

I am fairly sure that I  know why the LISP compiler was bombing out  on me.  The
trouble is that inside of an INTERNAL LAMBDA expression it will not allow you to
access any location that is  further away than 8  positions from the top of  the
stack.  I would  not be surprised if this is caused by  some confusion over BASE
and  IBASE.  I  have replaced  those EXPRs that  would not compile  by PROGs and
replaced the LAMBDA variables by PROG variables.  The entire system compiles now
with a  dramatic decrease in execution  time.  There  is a file on  my disk area
(MLISP) called CANBAD[L,HJS] which displays this erroneous behavior.